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Abstract 

We present a complete set of staging transformations for 
translating a class of interpreters into compilers and ex- 
ecutors. Staging transformation is the general process of 
separating stages or phases of a computation based on the 
availability of data. While encompassing partial evaluation, 
staging techniques can be more general, allowing for more 
powerful and flexible transformation strategies. We employ 
a particular strategy called pass separation that takes a pro- 
gram p and constructs a pair of programs pi , P2 such that 
p(x,y) — P2(pi(x),y) for all x, y. We apply this method in 
a restricted setting in which interpreters are described by 
abstract machines. For an interpreter p the pass separation 
constructs programs p\ and P2 corresponding to a compiler 
and an executor. The pass separation process includes the 
automatic definition of a semantics-directed machine archi- 
tecture that serves as the target code for the compiler. This 
architecture resembles abstract machine code generated by 
hand-crafted compilers. Though our method is restricted to 
a limited class of abstract machines given as term rewriting 
systems, we argue that this class encompasses a large set of 
machines derived from operational semantics. We provide 
an example of our method by transforming an SECD-like 
machine for call-by-value evaluation of the A-calculus into a 
compiler and executor for a variant of the Categorical Ab- 
stract Machine. 

1 Introduction 

The relationship between an interpreter for a language and a 
compiler/executor pair for the same language can be given 
informally in terms of separating computations of the in- 
terpreter into two stages of computations: one performing 
computations only on program structures (the compiler) fol- 
lowed by one performing computations primarily on run- 
time structures (the executor). Constructing such a com- 
piler/executor pair from an interpreter is an example of 
semantics-directed compiler generation when the interpreter 
represents the implementation of a semantics. Of course, a 
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typical interpreter may involve computation steps involving 
the manipulation of both program and runtime structures, 
and so the separation is a non-trivial process. 

We consider the task of taking an operational seman- 
tics for a source language and automatically defining an 
intermediate-level target language and a compiler from the 
source language to this target language. The target lan- 
guage represents a semantics- directed machine architecture 
[14] that has a very simple structure resembling machine 
code. Compiled programs have a corresponding resemblance 
to intermediate code produced by hand-crafted compilers. 
Our goal is to construct efficient implementations of oper- 
ational semantics using this technique. To accomplish this 
task we apply a form of staging transformation called pass 
separation [7] to an interpreter representing the operational 
semantics. While this method is very powerful, it lacks, in 
general, direct means of mechanization and automatization. 
Thus, constructing compilers from interpreters using this 
method typically requires manual intervention and applica- 
tion of transformations specific to individual interpreters. 

To make the process of pass separation more amenable to 
automatic methods we consider interpreters in a restricted 
form, namely abstract machines, in which computations are 
specified as rewrite rules operating on machine states, and 
each rule represents a single transition of the machine state. 
Note that interpreters in this form are iterative, as execu- 
tion of the machine entails the repeated application of re- 
duction rules until a final state is reached. Interpreters of 
this form are quite common and non-iterative ones can of- 
ten be translated simply into iterative ones. For example, 
a very common interpretation technique represents the in- 
put program as an abstract syntax tree and then performs 
a recursive traversal of this tree according to specific rules 
of evaluation. We can reorganize such a recursive proce- 
dure into an iterative one by introducing an explicit stack 
for storing recursive calls to the interpreter. 

To demonstrate our method of pass separation for con- 
structing compilers we consider an interpreter implement- 
ing call- by- value reduction of untyped A- terms to weak-head 
normal form (redexes within the scope of an abstraction are 
not reduced). We demonstrate how an abstract machine 
specifying an interpreter for such an evaluation strategy (a 
variant of Landin's SECD machine [10]) can be transformed 
into a compiler whose target code consists of instructions 
for manipulating environments and stacks (a variant of the 
Categorical Abstract Machine (CAM) [3]). The definition 
of this target language, given by an interpreter, is entirely 
automatic and depends only on the original interpreter. For 
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simplicity we present here a very simple language, but we 
have applied our methods to functional languages with ad- 
ditional features including constants, a conditional and re- 
cursion. 

The remainder of this paper is organized as follows. In 
Section 2 we present two general methods of staging trans- 
formations, partial evaluation and pass separation, and their 
general use in producing compilers from interpreters. We 
compare these two methods with respect to the specific goals 
outlined above. In Section 3 we present a formal definition 
for abstract machines specifying interpreters and discuss an 
example for interpreting a simple functional language. In 
Section 4 we introduce a simple transformation on abstract 
machines that provides a partial pass separation, producing 
stratified abstract machines that approximate compilation 
and execution stages. This step also introduces, in a com- 
pletely automatic fashion, new machine instructions. In Sec- 
tion 5 we define transformations on such stratified machines 
for producing a weak form of compilation and execution, 
in which the two stages are only partially separated. We 
then convert this weak system into a full one in which the 
stages are completely separated. In each of these sections, 
we use a machine performing call-by-value evaluation of the 
A-calculus as a running example and demonstrate how each 
of the concepts introduced apply to this machine. In Sec- 
tion 6 we compare our results with some related work and in 
Section 7 we summarize our results and conclude with some 
comments about generalizing and automating this work. 

2 Staging Transformations 

Staging transformations were introduced in [8] as a general 
approach to separating stages or phases of a computation 
based on the availability of data, with an immediate applica- 
tion to the development of compilers from interpreters. En- 
compassing concepts like partial evaluation and many com- 
piler optimization techniques (e.g. constant folding), staging 
addresses the general task of transforming a given program 
into an equivalent one characterized by distinct phases of 
computation. The archetypical example that we consider 
is an interpreter that can be decomposed into two stages 
representing compilation and execution. We describe two 
general strategies for staging: partial evaluation and pass 
separation. For both of these approaches we assume given 
a program p with two inputs x, y and the task of separating 
or staging the computations performed by p(x,y) into two 
sequential phases: one taking a value for x as input followed 
by one taking a value for y as input. (The value for x is 
"known" at an earlier stage than y.) In particular, we con- 
sider the case in which p is an interpreter operating on a 
program x and input y to program x. 

Partial Evaluation. Partial evaluation is the process of 
specializing a program p with respect to part of its input, 
say x, producing a new, residual program p x with the fol- 
lowing property: p(x,y) = Px(y) for all values x,y. Thus 
the partial evaluation step represents the first stage of a 
computation, and the application of the specialized program 
to the remaining input represents the second stage. This 
method of staging has the attractive feature of being general 
and automatable. The application of partial evaluation to 
semantics-directed compiler generation is well documented 
in the literature [7]. If we take p to be an interpreter, x to 
be a source program and y to be input data for x, then the 



partial evaluation stage produces a kind of compiled pro- 
gram p x . Execution is then just evaluating this program 
with input y. This approach to compiling programs (and 
the related approach of compiler generation) only requires 
an interpreter for the source language S (to be compiled) 
and a partial evaluator for the language T (in which the 
interpreter is implemented), producing residual programs in 
some fixed language H. The resulting compiler translates 
5-programs into 72-programs. Often T and 72. are the same 
language. If T and H are different languages then the partial 
evaluator must provide an explicit translation from T to %. 
Application of this method appears most successful when 
applied to an interpreter modeling a denotational semantics 
that is compositional, though non-compositional semantics 
can also be handled. Compositionality ensures a strong sep- 
aration of binding times between the source program and 
the input data manipulated by the interpreter, and this, in 
turn, ensures that a partial evaluator, such as Similix [1,2], 
can specialize the interpreter with respect to a given source 
program. 

Pass Separation. Pass separation is the process of con- 
structing from a program p a pair of programs pi , p2 such 
that p(x,y) = P2(pi(x), y) for all x,y [8]. The computation 
p(x, y) can therefore be split into a first stage computing 
Pi(x), yielding some value, say v, followed by a second stage 
computing p?(v,y). If we take p to be an interpreter, x to 
be a source program and y to be input data for x, then 
px is a compiler and p2 executes this compiled code on the 
data. For a given p, there may be many possible pi and p 2 
satisfying the above equation. Obviously, if p\ is the iden- 
tity program (f>(x) = x for all x) and P2 = p, then the above 
equation holds. The intention in performing pass separation 
is to "move" as many computations from p to p\ as possible. 
For example, if p does not depend on y, then we could let 
Pi(x) = p(x,c) (for any value c) and let p2(x,y) — x. So 
all the work is done by pi . Between these two extremes lie 
the more interesting definitions of p\ and p 2 ■ These defini- 
tions may introduce new data constructors not occurring in 
p that provide communication between the two stages. For 
the particular approach taken in this paper some of these 
new constructors will define an abstract syntax for a new 
abstract machine language. The compiler p\ will generate 
target code in this language and the program p2 will be an 
interpreter, providing a definition for this language. 

As discussed in the introduction, our goal is to automat- 
ically construct efficient implementations of operational se- 
mantics by directly generating compiled code in the form of 
some abstract machine language. Operational semantics are 
often not compositional and using only partial evaluation to 
generate compilers from them may not produce good results. 
To improve the performance of a partial evaluator we can in- 
troduce a preprocessing stage, prior to partial evaluation, in 
which binding-time improvements [5] are performed. For the 
example interpreter presented in the next section the Sim- 
ilix partial evaluator is unable to perform any specialization 
when applied to the interpreter and an input program, but 
if we reorganize the structure of the interpreter, achieving a 
binding-time improvement, then Similix is able to perform 
some specialization. Automating the binding-time improve- 
ment step is a current research activity. However, partial 
evaluation still provides no means for directly generating 
compiled code in a language other than the fixed one gener- 
ated by the partial evaluator. Assuming that the language 
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T implementing the interpreter is not a machine language, 
then the partial evaluator must either translate explicitly to 
a machine language H or produce "compiled" programs that 
require further translation or interpretation to execute (H 
is not a machine language). 

Pass separation, however, provides a means for achieving 
our goals. The method described in the following sections 
handles operational semantics that are not compositional, 
and it automatically defines an abstract machine language 
that serves as the target code for the generated compiler. 
The definition of the language is only dependent on the orig- 
inal operational semantics and is, in some way, "fine-tuned" 
explicitly for that semantics. Our use of pass separation can 
be directly related to the binding-time improvement phase 
found in the partial evaluation approach. Using a partial 
evaluator we can construct a compiler generator cogen that 
takes as input an interpreter and produces a compiler. If we 
preprocess an interpreter using binding-time analysis, then 
the construction of a compiler can be described as the com- 
position of programs (cogen o bta) in which bta performs 
binding-time analysis including binding-time improvements 
and binding-time annotations, labeling expressions as either 
static (reducible) or dynamic (irreducible) [7], Our use of 
pass separation corresponds to the binding-time improve- 
ment of bta and guarantees that the steps corresponding to 
binding-time annotation and cogen are trivial. 

3 Abstract Machines and Interpreters 

Abstract machines have been effectively used as interme- 
diate or low-level architectures suitable for supporting se- 
rious implementations of a wide variety of programming 
languages, including imperative, functional and logic pro- 
gramming languages. They facilitate portability, code opti- 
mizations and native machine code generation. Their simple 
structure makes them suitable for analysis and experimenta- 
tion. The structure of various architectures called abstract 
machines varies widely, depending in part on the language 
being described and also on the representation of source 
programs as data. We restrict our attention to abstract 
machines in which programs are represented as first-order 
abstract syntax trees, and we provide a general definition 
for a class of machines used to specify interpreters. 

We define abstract machines as term rewriting systems 
(TRS). We assume some familiarity with rewriting systems, 
its terminology and the notion of computation in a rewriting 
system. For our purposes, a TRS is a pair (E, R) such that 
E is a typed signature (a set of constants, each with a given 
type) and R is a set of directed equations {/, => rj}; e j with 
l„U e T S (X) and FV(r,) C FV(l,). Here, T S (X) denotes 
the set of first-order terms with constants from E and free 
variables from some set X, and FV(i) denotes the set of 
free variables occurring in t. We shall restrict our attention 
to first-order, linear systems, i.e. E is a first-order signature 
and there are no repeated variables in the lefthand side of 
any rule. If s and t are two E-terms and i is obtained from 
s via a single rewrite step using a rule from R we write 
s =S>r t; for multiple steps we write s => R t. A term t 
is terminal (with respect to a given TRS) if there does not 
exist a term u such that t =$-r u. 

For a given programming language C (that we wish to in- 
terpret), we assume given a typed signature E^ used for con- 
structing terms of type tm in a first-order abstract syntax, 
representing programs of C. We define a partial order C on 



these terms such that s C t iff depth(s) < depth(t) in which 
depth(t) is the depth of the abstract syntax tree representing 
t. Furthermore, we require that if k : n X • • • x r„—*tm g E^ 
for n > 1, then r, = tm for all i € [n]. That is, all subterms 
of a given term in the abstract syntax must also be terms in 
the abstract syntax. As an example consider the following 
signature: 

Ea = : tmxtm-^tm, A : im-»(m, 

0 : tm, +1 : tm—^tm}. 

Using this signature we can define an abstract syntax for 
the untyped A-calculus. The syntax uses de Bruijn notation 
for representing variables with ^ (infix) and A as the con- 
structors for application and abstraction, respectively. The 
constructors 0 and +1 (postfix) build up de Bruijn indices. 
For example, the S combinator \x\y\z.(xz)(yz) is repre- 
sented by the term AAA(((0+1)+1)"0)"((0+1)"0). 

We define a class of abstract machines motivated by pre- 
vious work on constructing abstract machines from oper- 
ational semantics [4]. We briefly review the structure of 
operational semantics and its relation to abstract machines. 
We view an operational semantics as axiomatizing a relation 
e 1| v, expressing the property that expression e evaluates 
to v (of some canonical form). Specifications of this sort are 
presented as sets of inference rules. Constructing a proof of 
e -li- v verifies that e indeed evaluates to v. Presentations of 
semantics in this form are often called structural operational 
semantics, as the rules are formulated such that bottom-up 
proof construction proceeds according to the structure of the 
expression e being evaluated. The following example, an op- 
erational semantics for weak, call-by-value reduction of the 
untyped A-calculus, should be compared with the abstract 
machine presented later in this section. 



{E,XM} ^ {E,XM} 

{E,M}^{E',XP} {E,N}^R {R::E',P)^V 
{E,M'N}$V 

{X::E,0}ii.X 

{E,n}VV 
{X::E,n+l} i±V 

{E, M} represents the closure of environment E and term 
M. An environment is itself a list of closures (using list 
constructor ::). In this example the only predicate symbol 
is More generally, however, other predicate symbols may 
be involved in defining an operational semantics. 

In [4] we demonstrated how a very natural class of op- 
erational semantics could be translated into abstract ma- 
chines, replacing the process of proof construction with one 
of rewriting. This translation provided a compilation of con- 
trol. In such abstract machines instructions ev(e) replace 
propositions e !)■ v. Additional instruction symbols replace 
other predicates occurring in the operational semantics. Us- 
ing these machines as a guide we define a class of abstract 
machines that corresponds to operational semantics. For 
notation, we use the following. For type r, (list r) is the 
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type of lists whose elements are all of type r. We use the 
list constructors nil, :: ("cons") and @ (concatenation), with 
the latter two infix. We abbreviate an :: 02 :: • • • :: a„ :: n»7 
as 3. 

DEFINITION 3.1 (Abstract Interpreter) An abstract 
macJiine for interpreting a language C, AM(C), is a TRS 
(E,R) such that 

1. E£ C E and k : n x • • • X r„-»im € E for n > 0 
implies k € E^; 

2. tJiere exist a distinguished type ins and a special con- 
stant ev : tm—*ins € E; 

3. tJiere exists a distinguished type data such that every 
rule in R is of the form (a :: C, v) => (<S@C, 10) for 
some terms a : ins, S : (/isi ins), v, w : data, and 
variable C : (list ins), and furthermore a is either of 
the form 

(a) ev(k(Xi , X„ k )) for k € E£ and variables X,; 
or 

(b) i(Xi X Kl ) for some 1 ^ ev and variables Xi; 

4. ifk € E£ then there exists at least one rule 

{ev(k(X 1 ,...,X nk ))::C, v) => (8@C, w) 

(for some v, w) in H. 

5. if (ev(t) :: C, v) =>• (S@C, w) is in H and a term 
ev(t') occurs in the list S then t' C t. 

The rules operate on machine states (u, v) in which u 
is a sequence of instructions, to be executed in order, and v 
is the data. (We assume that there are no proper subterms 
(«', v') in a term representing a machine state.) The restric- 
tions imposed by this definition on the structure of rules may 
appear severe, but they can be motivated by considering 
the relationship between these rules and the inference rules 
of an operational semantics. An inference rule has a sin- 
gle conclusion A and possibly many hypotheses Ai,...,A n 
and we might read a rule as saying: "to prove A we should 
prove At,.. . ,A n ." This suggests the general structure of 
our rules, in which the instruction a rewrites to the sequence 
of instruction a. C represents remaining instructions to exe- 
cute, corresponding to remaining propositions to prove. The 
v and w correspond to various kinds of data or auxiliary 
information, including environments and stacks, that have 
been separated from the instructions. The restrictions on 
the structure of a (in case 3) arise from our experience that 
"structural" rules for evaluation should only depend on the 
outermost constructor (k) of programs and any other rules 
should not rely on the structure of the programs. Case 4 
requires that evaluation be defined on all terms of the lan- 
guage, and case 5 requires that instructions ev(i) be defined 
in terms of strictly smaller instructions ev(t') (plus other 
possible instructions). These again come from our experi- 
ence with operational semantics in which all terms are given 
a structural semantics. 

Termination of an abstract machine can occur either suc- 
cessfully or unsuccessfully. Successful termination occurs 
when a machine reaches a state of the form (n»7, v), for 



some term v. Unsuccessful termination occurs when a ma- 
chine reaches a state of the form (u, v), for some terms 
u, v with u non-nil, and such that no rule of the machine is 
applicable to this state. 

We obtain a meaning for a term t, with respect to some 
data d (providing, for example, values for free variables in 
i), by constructing a rewrite sequence of the form 

(ev(t) :: nil, d) =>n (nil, d'). 

The meaning of t is then extracted from the term d'. An 
example will help clarify these ideas. 

The CLS machine of Figure 1 is a variant of the SECD 
machine [1 1] and an example of an interpreter AM(X). This 
particular description is the one obtained in [4] after apply- 
ing a series of transformations to a specification of call-by- 
value evaluation given as a set of inference rules. 0 and '•' are 
the environment constructors. 0 is the empty environment 
and if E is an environment then X ■ E is the extension of 
the environment with the new element X. {E,M} denotes 
the closure of term M with environment E. We overload 
the use of list constructors, using them to build instruction 
lists, environment lists and closure lists. The machine has 
two instructions: ev : tm—*ins and ap : ins. 

A state in the CLS machine is the pair (C, (L,S)) in 
which C is a list of instructions (terms to be evaluated), L 
is a list of environments and S is a stack of closures (com- 
puted values). Although Lan din's original description of 
the SECD machine uses a single environment, a dump and 
explicit variables names, our CLS machine contains essen- 
tially the same mechanism as that machine. To evaluate a 
given term t with respect to an environment e (providing 
values for the free variables <), we start the machine in the 
state (ev(t) :: nil, (e :: nil, nil)). When computation com- 
pletes successfully the machine stops in a state of the form 
(nil, (nil, x :: nil)) and the answer extracted (the value of 
<) is x. This machine can be extended to interpret a more 
complex language that includes base constants, primitive 
functions, a conditional expression and recursion. 

As an example of its operation, the following is the re- 
duction sequence performed by this machine for evaluating 
the A-term (A0)"(A0) with respect to the environment 0. 

(e»((A0)-(A0)) :: nil, (0 :: nil, nil)) 

=> (ev(XO) :: ev(XO) :: ap :: nil, (0 :: 0 :: nil, nil)) 
=> (ev(X0) :: ap :: nil, (0:: nil, {0, AO} :: nil)) 
(ap :: nil, (nil, {0, AO} :: {0, AO} :: nil)) 
(e«(0) :: nil, (({0, AO} • 0) :: nil, nil)) 
=> (nil, (nil, {0, AO} :: nil)). 

The result of evaluating (A0)"(A0) with respect to the 
empty environment 0 is the closure {0, AO}. 

While it is not necessary to represent the state of a ma- 
chine as a pair, doing so highlights the separation of the 
state into that part dealing only with instructions and the 
remaining auxiliary or data parts. This is motivated by our 
desire to stage the operations of the machine into compile- 
time and runtime phases. Manipulations on the program 
text will be done before the manipulation on the runtime 
structures. Our goal, then, is to transform an abstract ma- 
chine AM(C) for interpreting language C into a pair of term 
rewriting systems (C, X) in which C is a compiler, translating 
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Figure 1: The CLS machine 



^-programs into ^'-programs (for some language £') and X 
is an interpreter for £'. As we shall see, the target language 
£' depends upon the interpreter AM(C). 

4 Stratifying Abstract Machines 

The description of pass separation presented in Section 2 
relies on having a set of transformations that separates a 
computation into appropriate phases. In a general setting, 
there is no fixed procedure for performing such transfor- 
mations that achieves significant results. When we restrict 
our attention to abstract machines, however, the task be- 
comes much simpler. Recall that the rules Tl of an abstract 
machine are of the form (s, d) =*-tj (s' , d'). Pass sep- 
aration involves constructing two sets Hc,H-x of rewrite 
rules such that (u, v) =>k («', v') iff u =>r c u c and 
(« c , v) =^ti x («', v'). As suggested at the close of the 
previous section, if H is an interpreter, then He will be a 
compiler and Tlx the executor for the compiled code. 

Towards pass separation for AMs, we first define a trans- 
formation that will stratify an AM. The process of strati- 
fying involves transforming some rules (s, d) =>n (s', d') 
of a given AM into a pair of new rules: 

(s, Y)=* n ,( Sl , Y) (3 2 , d)=> n , (,', d') 

in which Y is a new variable and the si and S2 are new 
terms. Then some steps of a reduction sequence in Tl will 
be decomposed into two steps using these new rules. Note 
how the first of these rules essentially ignores its second ar- 
gument. Of course, we could let si = S2 = s, corresponding 
to the identity pass separation. The idea here is to use the 
first rule to perform as much computation (rewriting) as pos- 
sible on the term s, and then use the second rule to perform 
any remaining computation. For a given stratified AM, we 
refer to rules of the first kind as the compilation rules of the 
machine and rules of the second kind as the execution rules, 
suggesting the separation of these rules into a compiler and 
an executor. 

4.1 Stratified Abstract Machines 

We classify rules {s, d) (s', d') according to the occur- 
rences of free variables in s' and d'. Obviously, we must have 
FV(s') C (FV(s)UFV(d)) and FV(d') C (FV(s)U FV(d)) 
(definition of rewrite rules) and FV(s) D FV(d) = {} (lin- 
earity). 

We consider then the following two kinds of rules based 
on a further restriction. 



Pure: FV(d) fl FV(s') = {}. In this case the term s' is 
completely determined by s (FV(s') C FV(s)). Intu- 
itively, s' is typically the decomposition of s into sub- 
problems (or instructions operating on subterms of s). 
Note that d' may also contain free variables occurring 
in s. 

Impure: FV(d) n FV(s') ^ {}. In this case the term s' is 
not completely determined from just s. However, those 
parts of s' that are constant or contain only variables 
appearing in s can be determined from s. 

From these two cases we can describe transformations on 
rules based on their purity. For a given rule, we produce two 
new rules, one effectively operating on only the term s of the 
state and the other operating primarily on the the term d 
but via new "instructions" introduced by the compilation 
rules. We use the following notation. Lower case letters d, t 
denote terms that may contain free variables (the "schema" 
variables of rewrite rules). Upper case letters X, Y, C denote 
variables. Greek letters t and a denote instruction symbols 
and terms of type ins, respectively. We abbreviate ot\ :: • • • :: 
a k :: C as 3©C. 

TRANSFORMATION 4.1 (Stratified Abstract Ma- 
chine) Let (E, H) be an abstract machine. Then (E s , 7c s ) 
is tie smallest rewrite system such that ECS, and for each 
rule r E H, the following holds. 

1. Ifr is of the form (ev(i) :: C, d) => {a@C, d') then 

(a) ifr is a pure rule let {Xi,...,Xj} = (FV(t) n 
FV(d')) (j > 0); then H s contains the two rules 

(ev(t) :: C, Y) =!> rl 

{k(Xi X 3 )::S@C, Y) and 

{k(X 1 ,...,X J )::C, d)=> r2 (C, d') 

for some new variable Y and some new constant 
k : (mjx ••• xtmj-+ins € (E S \E) not occurring 
in any other rules of H s . 

(b) if r is an impure rule let { Xi , . . . , X, } = (F V(t) n 
(FV(S) U FV(d'))); then H, contains the two 
rules 

{ev{t) :: C, Y) => r i 

(k(Xi,...,X,)::C, Y) and 
{k(X 1 ,...,X 3 )::C, d)=* r2 (S@C, d'} 

for some new variable Y and some new constant 
k : tmiX ••• Xtm 3 -+ins £ (E S \E) not occurring 
in any other rules of H s . 
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2. Ifr is of the form (t(<i ,...,<„):: C, d) ==> {S@C, d') 
(i ^ ev) then r£U.. 

The new signature items k introduced by the transforma- 
tion correspond to new machine instructions for an abstract 
machine language and the execution rules introduced define 
this language. An important property of this transforma- 
tion is that for a given AM, new machine instructions are 
introduced and defined in a completely general and auto- 
matic fashion. If r 6 H, we write r s to denote the rule or 
pair of rules in H s corresponding to r. 

PROPOSITION 4.2 If (E, 11) is an abstract machine 
for some language C then so is (E s , H a ). 

The proof follows directly by observing that each of the rules 
introduced by Transformation 4.1 satisfies the requirements 
imposed on rules by Definition 3.1. Machines produced by 
this transformation are called Stratified Abstract Machines. 

Correctness of Transformation 4.1 is shown by proving 
that H and H 3 are equivalent systems with respect to the 
original signature E. 

THEOREM 4.3 Let (E, 7?.) be an AM and let (u, v) 
and («', v') be two E-terms. Then 

(it, v) =^ (it', v') iff (u, v) =*n, («', «')• 

The restriction to E-terms is necessary because H s can pro- 
duce terms (via rewriting) containing constants k € (E a \E), 
that H obviously cannot produce. 

PROOF. For the forward direction, we need only show 
that for all rules r € the single step reduction sequence 
(u, v) =>r («', v'} implies (a, v) =r-7i 3 i u> > v> ) 48 ^ on ly 
operates on E-terms. The proof proceeds by cases on the 
kind of rule used. If r is of the form (i(ti, ...,<„) ::C, d) => 
{3@C, d')) (t ^ ev) then the statement holds immediately 
as this rule is also in H. s . Assume r is of the form (e»(i) :: 
C, d) ==> (S@C, d') and Or = ((it, v) =4- r («', v')) for 
some substitution 8. That is, 6(ev(t) :: C) = u, dd = v, 
8(S@C) — it' and Qd' = v'. Then we have two cases to 
consider based on the purity of r. 

1. r is pure and {Xi,...,X } } = (FV(t) n FV(d')). Then 
r s is 

(ev(t)::C, Y) => rl (k{X u . . . ,X } ) :: 8®C, Y), 
(k(X„...,X J )::C, d)=> r2 (C, d') 

and by applying the substitution 6[Y i-» v\C *-* u'] 
to these two rules we can construct the following 7l s - 
reduction sequence: 

(«, v)=>ri {k(0X u ...,9Xj)::u', v) 

=>r2 («', «'). 

2. r is impure and {Xi, ... ,X 3 } = (FV(ev(t))n(FV(8)U 
FV{d'))). Then r s is 

(ev(t) ::C,Y) => rl (k(Xi X } ) :: C, Y), 

(k(X 1 ,...,X } )::C, d)=>r2{mC, d') 



and by applying the substitution 9[Y t-» v; C' i-+ #C] 
to these two rules we can construct the following H s - 
reduction sequence: 

(«, v)=> rl (k(9X 1 ,...,9X J ):.6C, v) 

We prove the reverse direction by induction on the length / 
of 7Z. s -sequences. 

1. 1=1. The sequence must be of the form 

(t(<i, . . . ,<n) :: u, v) =>r (8@u, w) 

for t € E and i ^ ev. Then r € H. and so this is also a 
TZ-sequence. 

2. / = 2. We have two cases to consider, based on the 
structure of the reduction sequence. 

(a) Assume the reduction sequence is of the form 

(ev(t) ::u, v) ==> r i (fc(si,.. . ,s } ) :: S@u, v) 

=>r2 {8@U, v'). 

Recall that k was chosen so that it occurred in 
only the two rules resulting from the translation 
of a single rule. Then rl and t2 are both in Tl s as 
a result of translating some pure rule r € 1Z with 
an instance 

(ev(t) ::u, v) => r {S@u, v') 

and this satisfies the statement. 

(b) Assume the reduction sequence is of the form 

(ev(t) :: u, v) => T l {k(si ,...,«,)::«, v) 

=*T2 {«', »')• 
Again, k was chosen so that it occurred in only 
the two rules resulting from the translation of a 
single rule. Then rl and rl are both in K a as a 
result of translating some impure rule r £ H with 
an instance 

(en(t) ::«, v) => r («', v) 
and this satisfies the statement. 

3. / > 2. Any 71,-sequence (u 0 , vq) =>n s ( M «> "«} 
starting and ending with E-terms must be a concate- 
nation of m sequences (tt < , v,) =*-7i 3 v,+i) (i € 
[0..m-l]) each described by one of the previous two 
cases. By induction we have («; , Vi) =t , k t't+i) 
for all i and concatenating these sequences we have 
(«o, ^o) =>ti {u n , v n ). □ 

For stratified abstract machines we can strengthen con- 
dition 4 of Definition 3.1 to: 

4'. if c € E^ then there exists exactly one rule 
(ev(c(X 1 ,...,X c )) ::C, v) => (8@C, w) 

(for any v,w) in H; 

Transformation 4.1 does not necessarily produce abstract 
machines that satisfy this stronger condition, but we can 
easily convert a stratified machine into one that does. We 
essentially merge rules (violating 4') into a single rule and 
modify other rules appropriately. We can safely assume that 
the stratified machines we manipulate always satisfy this 
stronger condition. 
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4.2 Stratifying the CLS Machine 

We now consider the application of Transformation 4.1 to 
the rules of the CLS machine given in Figure 1. This ma- 
chine is a simple example as the first four rules are all pure 
and the last rule is unchanged by the transformation. To 
facilitate readability, we shall choose new constants, as re- 
quired by the transformation, with mnemonic names sug- 
gesting their operation. 
For the first rule 

(ev(M'N) :: C, (E::L, S)) => 

(ev(M) :: ev(N) :: ap :: C, (E :: E :: L, S)) 

we introduce the new instruction symbol push : ins and 
then the two new rules we introduce for this rule are 

(ev(M~N) :: C, Y) =±> 

(push :: ev(M) :: ev(N) :: ap :: C, Y) and 

(pushv.C, (E::L, S)) ==> (C, (E :: E :: L, S)). 

For the second rule 

{ev(XM) :: C, (E::L, S)) =S> (C, (L, {E, XM} :: S)) 

we introduce the new instruction symbol lam : tm-^ins and 
then the two new rules we introduce for this rule are 

(ev(XM) :: C, Y) =*• (lam(M) :: C, Y) and 

{lam(M)::C, (E :: L, S)) => (C, (L, {E , XM) :: S)) . 

For the third rule 

(ev(0)::C, ((X-E)::L, S)) (C, (L, X :: S)) 

we introduce the new instruction symbol car : ins and then 
the two new rules we introduce for this rule are 

(ev(Q) C, Y) => (car :: C, Y) and 

(car :: C, ((X • E) :: L, S)) => (C, (L, X :: S)). 

For the fourth rule 

(ev(n+l) :: C, ((X ■ E) :: L, S)) => 
(ev(n)::C), (E :: L, S)) 

we introduce the new instruction symbol cdr : ins and then 
the two new rules we introduce for this rule are 

(ev(n+l) :: C, Y) (cdr :: ev(n) :: C, Y) and 

{cdr :: C, ((X ■ E) :: L, 5)) ^ (C, (E :: L, S)). 

Finally, the last rule 

{ap :: C, (L, X :: {E, XM} :: 5)) => 
{ev(M)::C, ((X ■ E) :: L, S)) 

just gets included in the stratified machine. 

The complete set of new rules yields the abstract ma- 
chine given in Figure 2. Although this machine is stratified, 
consisting of a compilation section (first four rules) and a 
execution section (last five rules), we have not achieved pass 
separation. The rule for ap essentially moves the computa- 
tion back to the compilation section. Intuitively, we can view 
the first four rules as describing a "lazy" compiler: given a 
term to be evaluated, only it's top-level constructor is com- 
piled. Subterms remain intact. The last five rules execute 



this compiled code, and when necessary, they reinvoke the 
compiler. In the next section, we discuss how to complete 
the pass separation. 

As an example of reductions performed by this machine 
we again consider the evaluation of the A-term (A0)"(A0): 

<ev((A0)-(A0)) :: nil, (0 :: nil, nil)) 

=>■ {push :: ei>(A0) :: ev{X0) :: ap :: nil, (0 nil, nil)) 
=> (ev(X0) :: ei>(A0) :: ap :: nil, (0 :: 0 :: m7, nil)) 

(/am(0) :: ev(XO) :: ap :: nil, (0 :: 0 :: nil, nil)) 
=> {ev(XO)::ap::nil, (0 :: nil, {0, AO} :: nil)) 
=> {lam(0)::ap::nil, (0 :: nil, {0, AO} :: nil)) 
=^ (ap-.-.nil, {nil, {0, AO} :: {0, AO} :: nil)) 

(ei>(0) :: nil, (({0, AO} • 0) :: nil, nil)) 

(car :: nil, (({0, AO} . 0) :: nil, nil)) 

{nil, (nil, {0, AO} :: nil)). 

5 Compilation and Execution Stages 

In this section we transform the compilation and execu- 
tion sections of stratified machines into completely separated 
stages. This process is done in two steps. First, we produce 
weak compilers and executors that do not completely sepa- 
rate the task of compilation from execution. Then we extend 
these weak systems to full ones, with compilers generating 
code in which all source terms are reduced to a compiled 
form and executors manipulating only compiled code. 

5.1 Weak Compilers and Executors 

A weak compiler is a term rewriting system that translates 
a source program to a target program in which parts of 
the original source program may occur. A weak executor is 
a term rewriting system that may reinvoke the weak com- 
piler during execution to compile remaining parts of a source 
program before continuing with execution. We demonstrate 
how a stratified abstract machine can be transformed into a 
pair of such rewrite systems. 

Every rule in the compilation section of a stratified ab- 
stract machine is of the form 

(ev(t) C, Y) (3@C, Y) 

for some term t and some instructions a. These rules define 
how one ev instruction expands into a sequence of instruc- 
tions, independent of the argument Y. These rules define 
a very weak form of compilation in which only the first in- 
struction in the list gets compiled (and then immediately 
executed). We can generalize this idea by allowing such ev 
instructions, occurring anywhere in an instruction list, to be 
reduced. Taken to the extreme, we can reduce all ev instruc- 
tions prior to executing any others, possibly eliminating all 
ev instructions. Of course, the current description of an ab- 
stract machine prohibits such rewriting on subterms. We 
can allow such rewriting by applying the following transfor- 
mation. 

TRANSFORMATION 5.1 (Weak Compiler and Ex- 
ecutor) Let (£, TV) be a stratified abstract machine. 
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Figure 2: Stratified CLS machine 



1. The weak compiler for this machine is the smallest 
rewrite system (E, H-wc) such that 

(ev(t)::C, Y) (S@C, Y) € 11 

implies 

ev(t) :: C => 3@C € "R-wc 

2. The weak executor for this machine is the smallest 
rewrite system (E, H we ) such that 

{i(X u ...,X n )::C, v)^{a@C, w) € H 

(i / ev) implies 

(t(Xi ,...,X„)::C, v)=> 0@C, w) € n w * 

where 0 is obtained from 5 by replacing each subterm 
ev(t,) ::uofa with (3i@u such that ev(t,) ::nil =f-^ Zwc 
/?, and /?; is terminal (with respect to H W c)- 

We write (E, H w ) for (E, H wc U 7l we ). 

The rules of the weak compiler allow terms ev(t) occurring 
anywhere in the instruction sequence to be reduced while in 
a stratified machine only the first instruction could ever be 
reduced. The weak compiler is, however, confluent. Case 5 
of Definition 3.1 ensures that a weak compiler has no infinite 
reduction sequences and this ensures that a weak executor 
is well defined. The term /? can always be constructed using 
the weak compiler. Though perhaps not apparent, the weak 
executor has the property that for any rule 

(i(X lt ...,X n )::C, v)^0@C, w) 

if ev(t) occurs in /?, then t is a variable. This property is 
not essential for the definition of a weak executor, but it is 
convenient to require it here. It will be exploited when we 
construct a full compiler. 

Note that the resulting set of rules is no longer an ab- 
stract machine. The compiler is weak in the sense that some 
terms do not get fully reduced via these rules, requiring the 



executor to invoke the compiler during its operation. In 
fact, precisely those rules introduced by Transformation 4.1 
in which j > 0 (k has a non-zero number of arguments) 
produce such non-reduced terms. 

THEOREM 5.2 Let (E,ft) be a stratified abstract ma- 
chine. Then for any terms Uo,v 0 ,v„, {u 0 , v 0 ) ==>n {nil, v n) 
iff («„, v 0 ) =3>n w {nil, v n ). 

That is, the successful termination property is preserved by 
Transformation 5.1. Note that reductions via % w may con- 
tain intermediate terms not reachable via Tt, due to the 
flexible reduction order allowed by 7t w . Though the weak 
compiler is confluent, the weak executor may not be. In par- 
ticular a stratified machine (E,ft) is confluent iff (E, H we ) 
is confluent. 

Applying Transformation 5.1 to our stratified CLS ma- 
chine in Figure 2, we obtain the weak compiler and executor 
in Figure 3. It is only a weak compiler because of the rule for 
compiling A-abstraction. As an example of this weak com- 
piler and executor we again consider evaluating the term 
(A0)"(A0). Theorem 5.2 allows us to employ any rewriting 
strategy for Tl w and so we choose the strategy in which we 
will always reduce ev instructions (left-to-right using *R*wc) 
before reducing any other instructions (using Tl wc ). 

(ev((A0)-(A0)) :: nil, (0 :: nil, nil)) 
=$- {push :: ev(AO) :: ev(AO) :: ap :: nil, (0::niJ, nil)) 
=> {push :: lam(0) :: eu(AO) :: ap :: nil, (0 :: nil, nil)) 
=>• {push :: lam(0) :: lam(0) :: ap :: nil, (0 :: nil, nil)) 
=>■ </am(0) :: /am(0) :: ap :: nil, (0 :: 0 :: nil, nil)) 
=>■ (fam(O) :: ap :: nil, (0 :: nil, {0, AO} :: nil)) 
=> (apv.nil, (nil, {0, AO} :: {0, AO} :: nil)) 

(ei>(0) :: nil, (({0, AO} • 0) :: nil, nil)) 
=> {car :: nil, (({0, AO} • 0) :: nil, nil)) 
=>• (nil, (nil, {0,AO} ::nil)). 



137 







ev(M'N) 


::C 




push :: ev(M) 


:: ev(N) :: ap :: C 






ev(XM) 


::C 






lam(M) ::C 






ev(0) 


:: C 


=> 




car :: C 






ev(n + l) 


:: O 






car :: ev{n ) :: O 


( a p '■ 


:C, (L, X::{E,XM}:: 


s)) 




(cv{M) :: C, 


((X • £) :: I, <?)> 


{ push : 


:C, 


(E::L, 


S)) 




( c, 


(E::E::L, S)} 


(lam(M) : 


:C, 


(E::L, 


S)) 




{ c, 


(L, {E,XM}::S)) 


( car : 


■ c, 


((X-E)::L, 


S)) 




( c, 


(L, X::S)) 


{ cdr : 


:C, 


((X-E) ::L, 


S)) 


=4- 


( c, 


(E :: L, S)> 



Figure 3: Weak Compiler and Executor for CLS 



5.2 Full Compilers and Executors 

A full compiler is a term rewriting system that rewrites 
a source term into a compiled form in which no source 
terms occur. A full executor is a term rewriting system 
that rewrites such compiled code without manipulating any 
source terms. We can convert weak compilers and executors 
into full ones. We consider first the case for compilers and 
then consider executors. 

The rules of a weak compiler are all of the form 

ev(t) :: C a@C 

and S is a list of terms of the form ev(t') or i(Xi , . . . , X,) 
with each X, of type tm. (As they are variables, they must 
occur on the lefthand side of the rule, and hence in the term 
< : tm.) It is exactly the instructions of the latter form that 
make the compiler weak, as the arguments to these instruc- 
tions cannot be reduced further by the compiler. To make a 
full compiler, in which every source term is completely elim- 
inated via rewriting we modify these rules, allowing further 
reduction on the X{. 

TRANSFORMATION 5.3 (Full Compiler) Let (£, 
H) be a weak compiler. We construct the full compiler 
(£/,7l/) as follows. 

1. E/ is obtained from E by replacing all instruction sym- 
bols i : tmi x ■ ■■ x tm„^ins € E for i ^ ev and n > 1 
with new symbols t' : (list ins)i x- • -x(list ins) 

2. Ttj is obtained from H by replacing all rules ev(t) :: 
C =S- <3@C in H with ev(t) :: C 3'@C in which 
3' is obtained from 3 by replacing every list element 
t(Xi, . . . ,X n ) (i ^ ev and n> 1) in a with i'(ev(Xi):: 
nil, ... , ev(X n ) :: nil). 

The justification for the term full compiler is provided 
by the following proposition. 

PROPOSITION 5.4 Let (E, TZ) be a weai compiler (for 
language C) and let (E/, Hf) be the full compiler obtained 
via Transformation 5.3. For every E^-term t there exists 
some term u c containing no E £-subterms such that ev(t) :: 
nil =>k u c with u c terminal. 



We say that u c is the compiled form of t. Compiled forms 
are guaranteed to exist in part because of the restriction 
on rules of abstract interpreters imposed by case 5 of Def- 
inition 3.1. It should be clear that two £-terms have the 
identical compiled form if and only if they are identical. 

We now return our attention to weak executors and de- 
scribe how they can be transformed to manipulate the code 
generated by full compilers. We start from the assumption 
that our full executor should not manipulate any source 
terms. One aspect of this assumption is easily explained. 
We can require that the input program is first completely 
compiled by the full compiler, eliminating any source terms 
(as guaranteed by Proposition 5.4). Unfortunately, the in- 
put data v may also contain source terms. Replacing these 
terms with their compiled forms requires a little extra work. 
First we focus on constructing a full executor and then we 
discuss how to handle the data. 

TRANSFORMATION 5.5 (Full Executor) Let (E, 
TV) be a weak executor. We construct the corresponding full 
executor (E/, Hj) as follows. 

1. Yjf is obtained from E by replacing all elements k : 
t 6 E with new elements k' : r' in which r' is ob- 
tained from r by substituting the type (list ins) for 
all occurrences of the type tm in t. (If tm does not 
occur in r, we will just keep the same symbol k.) 

2. Tlj is obtained from TZ by replacing all rules 

{a :: C, v) (3@C, w) 
with 

(a* ::C, v*) =J- (3*@C, w*) 

where (■)* : Te(X)—+Tzj (A"*) is the function defined 
by cases as 

(ev(X,) ::»)* = X;@u'; 

c*(*i *»»• = *'(*; 

We assume that (•)* defines a bijection between the 
variable sets X and X* . 
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Figure 4: Full Compiler and Executor for CLS 



The general idea of this transformation is that the ex- 
ecutor should manipulate compiled code given by lists of 
instructions (type (list ins)) instead of source terms (type 
tm). Step 1 introduces new constructors that take compiled 
code instead of source terms, and step 2 modifies each rule 
so that variables representing source terms are replaced by 
variables representing code. As the only terms of type tm 
occurring in any rule of a weak executor are variables, this 
step eliminates all terms of type tm in the new rules. It 
should be clear that the resulting rules contain no occur- 
rences of ev (or ev'). 

Before comparing the full compiler and executor with 
corresponding weak ones we need to consider the input data 
vo. Assume we are given some initial state (uo, vo). We 
could first compile the term uo using a full compiler, pro- 
ducing a compiled program in which all source terms have 
been eliminated. This program and the data could then be 
executed by a full executor. The initial data vo, however, 
may contain source terms and the executor cannot manipu- 
late them. We have a compiler for E^-terms and we could 
compile those (maximal) E^-terms occurring in vo, addi- 
tionally replacing constructors k in vo with their "compiled" 
form k'. For any term v, let comp(y) be the result of this 
translation. We then can provide the following relationship 
between weak and full compiler/executor systems. 

THEOREM 5.6 Let (E, H c ) and (E, H x ) be a weak com- 
piler (for some Janguage C) and a corresponding weak ex- 
ecutor. Let (E/, TVj) and (E^, H x ) be the full compiler and 
corresponding full executor obtained from these by Trans- 
formations 5.3 and 5.5. Then for all uo,vo, v m , 

(u 0 , «o)=>TC c u7t :r ( n, '> v ">) 
iff there exist u c , v n such that 

uo =^jc u c (for u c terminal), 

(«c comp(vo)) =^k x { n *h v n) an <^ 

comp(v m ) — v n . 



If we apply Transformations 5.3 and 5.5 to the machine 
produced in Figure 3 we obtain the full compiler and execu- 
tor in Figure 4. This is essentially the Categorical Abstract 
Machine [3] without pairing. (Our instruction ap is cur- 
ried while the CAM's app is uncurried.) The constructor 
X' replaces A in the executor, as we now store the com- 
piled code, instead of the source term, for the body of a A- 
abstraction. Given a A-term t, we compile it via the rewrite 
sequence ev(t) :: nil =>•* u c such that u c is terminal. Then, 
given some initial environment list lo and stack so (in com- 
piled form), we execute the code via the rewrite sequence 
(«e, (/o,so)) ==*>* •••• 

As an example of this compiler and executor we again 
consider evaluating the term uo = (^O)'(AO) with vo = (0 
nil, nil). Note that comp(vo) = t»o- First we compile uo 
using the compiler: 

ev((A0)-(A0)):: nil 

=3- push :: ev(XO) :: ev(XO) :: ap :: nil 

push :: lam(ev(0) :: nil) :: eu(AO) :: ap :: nil 
push :: lam(ev(0) :: nil) :: lam(ev(0) :: nil) :: ap :: nil 
=*■ push :: lam(car :: nil) :: lam(ev(Q) :: nil) :: ap :: nil 
=> push :: lam(car :: nil) :: lam(car :: nil) :: ap :: nil. 

Then we execute this program with data comp(vo): 
(push :: lam(car :: nil) :: lam(car :: nil) :: ap :: nil, 
(0:: nil, nil)) 

=> (lam(car :: nil) :: lam(car :: nil) :: ap :: nil, 
(0 :: 0 :: nil, nil)) 

(lam(car :: nil) :: ap :: nil, 
(0:: nil, {0, X' (car :: nil)} :: nil)) 

{ap :: nil, 

(nil, {0, A'(car :: nil)} :: {0, A'(cor :: nil)} :: nil)) 
=> (car :: nil, (({0, A'(car :: nil)} ■ 0) :: nil, nil)) 

=^ (nil, (nil, {0, \'(car :: nil)} :: nil)). 
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We can now describe the relationship between our origi- 
nal CLS machine in Figure 1 and this final one in Figure 4. 
Let (£,72.*) denote the CLS machine in Figure 1. Let H c 
and 1Z X be the sets of rules given in Figure 4. 

THEOREM 5.7 For all Z-terms u 0 , v 0 , v m , 

iff there exist u c , v n such that 

uo =^c u c (for u c terminal), 
(u c , comp(vo)) =>k x Vn )< 
and comp(vm) = v n . 

The proof follows immediately from the correctness of each 
of the transformations described in this paper. Thus we have 
the constructed a provably correct compiler and executor 
from an interpreter. 

6 Related Work 

This work can be seen as a continuation of the work pre- 
sented in [4] for constructing efficient implementations of 
operational semantics. The scope of that work concerned 
translating operational semantics, given as sets of inference 
rules, into abstract machines. This translation can be viewed 
as a process operating on control constructs. The current 
work considers translating the resulting abstract machines 
into compilers and executors. This translation can be viewed 
as a process operating on language constructs. 

This work is an example of semantics-directed compiler 
generation, the process of constructing compilers directly 
from a language's semantics [6]. Several other approaches to 
this problem have been explored. One of the first used par- 
tial evaluation for constructing compiled programs, compil- 
ers and compiler generators from semantic definitions viewed 
as interpreters [7]. Part of this work can be viewed as an ef- 
fort to eliminate the overhead of interpretation by construct- 
ing specialized versions of an interpreter. In generating the 
specialized or residual programs a partial evaluator performs 
reductions and simplifications by exploiting known or static 
information provided as input. This method of compiler 
generation has exhibited significant success. 

A second approach, related to partial evaluation, uses 
denotational semantics for constructing compilers (for ex- 
ample [13]). In this setting the denotational semantics of a 
language defines a translation from the language to A-terms, 
which can be viewed as either intermediate or target code. 
An implementation of A-calculus reduction provides a means 
for executing this code. A straightforward application of this 
idea typically produces large target programs and inefficient 

implementations. Methods to improve the generated code 
include partially evaluating the target code. A related ap- 
proach uses high level semantics, a semantics specification 
language suitable for defining the meaning of programming 
languages and for describing the implementation of realistic 
compilers [12]. 

Another approach uses a transformation-based strategy 
for compilation in which source programs are first translated 
manually into an intermediate language that is a slightly en- 
riched A-calculus with a call-by- value semantics. A compiler 



then simplifies and translates this code into an abstract ma- 
chine language [9]. The compiler employs a transformation 
strategy that removes any operations or dependencies from 
the intermediate language that the target machine cannot 
directly implement. This approach is similar in spirit to the 
work reported here, in that transformations are applied to 
produce a program in a specific form. 

The construction of a semantics-directed machine archi- 
tecture has also been considered using denotational seman- 
tics [14,15], The general idea of this work is to rewrite 
the semantic definitions of a language using special-purpose 
combinators, dependent upon the original definition. This 
is similar to our construction of a target language based 
on the operational semantics of a language. Unfortunately, 
the transformation processes described in these works are 
neither mechanical nor automatic as the definition of new 
combinators (abstract machine instructions) requires man- 
ual intervention. 

The original definition of the Categorical Abstract Ma- 
chine (CAM) is based on the idea of categorical combina- 
tors considered as machine instructions [3], Although not 
describing a general framework for constructing compilers, 
this work provides a connection between categorical combi- 
natory logic and the implementation of functional languages. 
Properties of the logic can be used to understand the oper- 
ation of the machine and the nature of compilation. Unfor- 
tunately, the construction of a compiler (for the A-calculus), 
though guided by the relationship between the A-calculus 
and cartesian closed categories, is not automatic, and con- 
sequently the correctness of this compiler with respect to an 
operational semantics must be shown. Using our pass sep- 
aration technique, constructed compilers and executors are 
guaranteed correct with respect to the original operational 
semantics. 

Finally, the task of mechanically defining an abstract ma- 
chine has also been considered for Prolog [10]. This work 
uses partial evaluation to simplify a Prolog interpreter (writ- 
ten in Prolog) in which operations such as unification have 
been made explicit. To reduce the size of the residual in- 
terpreter new "instructions" or predicates are manually de- 
fined to replace expressions occurring repeatedly in the in- 
terpreter. This introduction of new instructions is similar 
to the approach taken in our work, though our process is 
entirely automatic. 

7 Summary 

We have presented a method for converting interpreters spec- 
ified as abstract machines into compilers and executors. We 
employed pass separation, a particular strategy for staging 
transformations, for separating the computations of an in- 
terpreter into two distinct phases. Restricting the scope of 
staging transformations to abstract machines provided a set- 
ting in which computations, given as reduction sequences, 
could be analyzed and decomposed into separate reduction 
sequences in which source terms were first eliminated and 
then data was manipulated. The problem of incomplete 
transformations, typical of staging in general, was overcome. 
While our definition for interpreters is a bit restrictive we 
argued that it defines a very natural class of abstract ma- 
chines derived from operational semantics. Though the ex- 
ample language considered was particularly simple we have 
successfully tested our methods on slightly larger languages. 
Empirical results are required to gain further confidence in 
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the range of application for our transformations. 

An interesting product of our staging transformations is 
the construction of a semantics-directed machine architec- 
ture as the target for the constructed compilers. Previous 
work in constructing such abstract machine languages based 
on a source language's semantics often required clever ob- 
servations dependent upon the particular semantics. Our 
method is completely mechanical and automatic, and it ap- 
plies to the class of abstract interpreters that we have de- 
fined. 

To ensure the termination of compilers and to simplify 
other aspects of our methods we imposed several restrictions 
on the structure of abstract machines. While our definition 
of abstract interpreter captures a useful class of interpreters, 
we would like to consider relaxing some of these restrictions 
by providing additional transformations to handle a more 
general class of abstract machine. 

None of the transformations presented in this paper re- 
quire any special kind of flow analysis or other complex in- 
spection to test their applicability, as is sometimes found 
with other kinds of transformation strategies. The simple 
syntactic conditions required for our methods, such as the 
restriction of certain sets of free variables, are conditions 
that can be determined in time proportional to the size of 
the rules. Thus, our methods appear immediately mecha- 
nizable and automatable and future work will consider the 
specification of these rules in a formal system. 
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